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(54) System and method for delivery of information over narrow-band communications links 



(57) System and method for delivery of information 
over narrow-band communications links. The system 
has at least a browser (12), a mobile client (10), a fixed 
server (30) and an origin host (50). The browser (12) 
requests a resource. The mobile client (10) transmits 
the request to the fixed server (30). The fixed server 
(30) retrieves a primary resource from the origin host 
(50) and any dependent resources. The fixed server 
(30) transmits the primary resource to the mobile client 
(10). The mobile client (10) transmits an acknowledg- 
ment list to the fixed server (30) requesting certain 



dependent resources and sends the primary resource 
to the browser (12). The fixed server (30) transmits the 
requested dependent resources to the mobile client (10) 
in one transmission. The mobile client (10) sends the 
dependent resources to the browser (12) upon request. 
Thus, only transmitting two round-trips of data across 
the narrow-band communications link to transfer all the 
necessary data to create an entire information page 
reduces the delay significantly. 
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Description 

Field of the Invention 

This invention relates to efficient delivery of infer- 5 
mation to browser clients over wide-area, narrow-band 
communications systems, including, but not limited to. 
Packet Data Networks and Circuit Switched Networks. 
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Background of the Invention 

The World Wide Web (Web) is an ubiquitous com- 
munications network used to readily access available 
resources on many computers throughout the world and 
is attached to at least one computer network known as is 
the Internet. The Web comprises a body of software, a 
set of protocols and a set of defined conventions for 
obtaining information on the Web. The Web utilizes 
hypertext and multimedia techniques to make the Web 
"user-friendly" for anyone who desires to browse, roam 20 
or contribute to the Web. 

A HyperText Transport Protocol (HTTP) is a proto- 
col that is used for transporting hypertext files across 
the Internet. In ordinary HTTP operation, a proxy 
receives an HTTP request for a resource and connects 25 
to a host identified in a uniform resource locator (URL). 
A URL is a standardized way of representing different 
documents, media and network services on the Web. 
The proxy retrieves the resource and returns a HTTP 
response to the requester. 30 

In normal HTTP operation, the browser requests a 
HyperText Markup Language (HTML) response. A 
HTML is a standardized way to creak hypertext docu- 
ments for use on the Web; HTML is a coding language 
that surrounds the text used in the hypertext documents 35 
with codes and brackets to indicate how the text should 
appear to the user. When the browser receives the 
HTML response, the browser parses it and issues indi- 
vidual requests for dependent resources, such as in-line 
images Over a narrow-band, high latency connection, 40- 
this "ping-ponging" (e.g., the browser requesting and 
receiving each dependent resource individually) results 
in a severe delay in completing the retrieval of an entire 
Web page. For a page containing N in-line resources 
retrieved over a link with an average round-trip latency 45 
of L seconds, the delay is approximately ((N+1)*L) sec- 
onds. 

As a result of delays in delivery of information over 
narrow-band communications links, there exists a need 
for a system that delivers information to browser clients so 
over wide-area, narrow-band communications systems 
in an efficient manner. 

A preferred embodiment of the invention, is now 
described, by way of example only, with reference to the 
drawings. 



Brief Description of the Drawings 

The features of the present invention are set forth 
with particularity in the appended claims. Preferred 
embodiments of the invention are now described, by 
way of example only, with reference to the accompany- 
ing drawings in which: 

FIG. 1 is an overview diagram of a wireless Web 
proxy system according to a preferred embodiment 
of the invention; 

FIG. 2 is a bounce diagram of the preferred embod- 
iment of the invention; 

FIGS. 3 and 4 together are a flow chart of an oper- 
ation of a mobile client according to the preferred 
embodiment of the invention; 
FIGS. 5 and 6 together are a flow chart of an oper- 
ation of a fixed server according to the preferred 
embodiment of the invention; 
FIG. 7 is a flow chart of a method of operation for a 
cache check according to the preferred embodi- 
ment of the invention; and 

FIG. 8 is a bounce diagram of an alternative 
embodiment of the invention. 



It will be appreciated that for simplicity and clarity of 
illustration, elements shown in the figures have not nec- 
essarily been drawn to scale. Where considered appro- 
priate, reference numerals have been repeated among 
the figures to indicate corresponding elements. 

Detailed Description of the Drawings 

A wireless Web proxy system, which is now 
described, is a system of middleware software which 
functions as a HTTP proxy incorporating a proprietary 
protocol for communication of HTTP requests and 
responses. The wireless Web proxy system provides 
the means for efficient delivery of information (e.g.. Web 
content) such as text, images, sounds, and other 
resources, accessed via the HTTP protocol over Trans- 
port Control Protocol/ Internet Protocol (TCP/IP) net- 
works (Intra-/ Internet) to browser clients over wide- 
area narrow-band communications systems, including, 
but not limited to, Packet Data Networks (e.g., DataTAC 
4000/ 5000/ 6000. Mobitex. CDPD. etc.) and Circuit 
Switched Networks (e.g., Analog Cellular, GSM. etc.). 

As shown in FIG. 1 , the wireless Web proxy system 
consists of mobile proxy software 14 installed on a dig- 
ital processor/ mobile client 10 and fixed proxy software 
32 installed on a digital processor/ fixed server 30. The 
mobile proxy software 1 4 implements an interface which 
conforms to the specification contained in RFC 1945, 
"Hypertext Transfer Protocol » HTTP/1 .0" for an HTTP 
1.0 complaint proxy server. The digital processor 10 
comprises at least the following components: a browser 
12 the mobile proxy software 14. a winsock 22 and a 
radio frequency transport 24. The mobile proxy software 
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14 further comprises at least a resource transceiver 16 
and an acknowledgment list generator 18 having at 
least a comparator 20. Connected to the mobile proxy 
software 1 4 of the digital processor 1 0 is a cache 26 and 
a radio transceiver 28. The wireless Web proxy system 
further comprises a memory having instructions and 
data stored therein that, when executed, causes the dig- 
ital processor 10 and the cache 26 to comprise the 
resource transceiver 16 with an input 17 couplable to . 
the browser 12 and an output 15. The acknowledgment 
list generator 18 has a first input 19 coupled to the out- 
put 15 of the resource transceiver 16, a second input 21 
coupled to the cache and an output 23 couplable to the 
radio transceiver 28. Such a configuration allows the 
comparator 20 to compare the received resources with 
the cached resources. 

The fixed proxy software 32 is installed and exe- 
cuted on the fixed server PC running Windows NT 3.51 
or later. The fixed proxy software 32 implements the 
HTTP 1 .0 client protocol and is responsible for retrieving 
resources from HTTP servers (Web servers) on the 
Internet or Intranet. The digital processor 30 comprises 
at least the following components: the fixed proxy soft- 
ware 32, a winsock 40 and a radio frequency transport 
42. The fixed proxy software 32 further comprises a 
resource transceiver 34 and a summary response 
builder 38. Connected to the fixed proxy software 32 of 
the digital processor 30 is a cache 44 and a radio trans- 
ceiver 46. The wireless Web proxy system further com- 
prises a memory having instructions and data stored 
therein that, when executed, causes the digital proces- 
sor 30 to comprise the resource transceiver 34 and the 
summary response builder 38. The summary response 
builder 38 is coupled to the resource transceiver 34. The 
summary response builder 38 has an output 39 which 
provides a summary response which includes a plurality 
of status codes corresponding to a plurality of requested 
resources and includes the requested resources when 
available. The summary response comprises contents 
from a plurality of resources which when taken together 
with resources cached locally at the digital processor on 
the mobile client constitutes an entire information page 
(e.g., a Web page). In addition, the radio transceiver 46 
is coupled to the output 39 of the summary response 
builder 38 for sending the summary response over a 
communications link to the browser 12. 

A mobile user begins browsing by launching the 
mobile proxy software 14. This automatically launches 
the user's preferred Web browser software. The mobile 
user can browse the Web by entering uniform resource 
locators (URLs) by following links as he/she is normally 
accustomed to doing in a wire-line environment (e.g., on 
a Local Area Network). 

FIG. 2 is a bounce diagram of the preferred embod- 
iment of the invention. In FIG. 2, the browser 1 2 and the 
mobile proxy software 14 are the primary components 
which comprise the mobile client. Also shown in FIG. 2 
are the fixed proxy software 32 and the origin host (e.g., 



Web site) 50. Requests and responses are exchanged 
between the mobile client and the fixed server over a 
narrow-band communications link (e.g., the transmis- 
sions between the mobile proxy software 14 and the 
5 fixed proxy software 32). As shown, the wireless Web 
proxy protocol only requires transmitting two round-trips 
of data across the narrow-band communications link to 
transfer all the necessary data which when taken 
together with the resources cached locally at the mobile 
70 client constitutes an entire information page (e.g., Web 
page). By reducing data transfer over the narrow-band 
communications link to a total of two-round^trips, the 
delay is reduced to 2*L seconds, where the average 
round-trip latency over a narrow-band communications 
;5 link is L seconds. 

FIGS. 3 and 4 together are a flow chart of an oper- 
ation of a mobile client 10 according to the preferred 
embodiment of the invention. The mobile user's browser 
12 is configured to treat the mobile software as a Web 
20 proxy server. In FIGS. 3 and 4, when the mobile user 
opens a URL, the browser 12 submits an HTTP request 
to the mobile client 10. The mobile proxy software 14 
receives the HTTP request and examines its local 
cache (a database of URL-indexed information) at steps 
25 102 and 104. The manner in which the mobile proxy 
software 14 examines its local cache 26 is described 
below in conjunction with FIG. 7. The mobile client 10 
determines at step 106 whether it can respond to the 
browser 12 immediately or whether it must ask for the 
30 information from the fixed server over the narrow-band 
communication link. If the mobile client 10 already has 
certain resources cached (e.g., already has received a 
page before expiration), then the mobile proxy software 
14 informs the fixed proxy software 32 not to send the 
35 resources that are cached at the mobile client 10 and 
the mobile proxy software 14 sends the HTTP response 
to the browser 12 at step 108. However, if the mobile cli- 
ent 10 decides that it must forward the request to the 
fixed server 30 because the resource is not cached or 
40 the resource has expired, the mobile proxy software 14 
transmits the request to the fixed server in the form of a 
tokenized and compressed HTTP request at steps 110 
and 112. The manner in which the HTTP request is 
tokenized is described below. Thus, from step 112, the 
45 operation of the mobile client pauses before proceeding 
to step 136. During this time, certain steps are per- 
formed at the fixed server, as shown in FIGS. 5 and 6. 

In FIGS. 5 and 6, the fixed server 30, upon receiv- 
ing the HTTP request at step 114, expands the token- 
so ized and compressed HTTP request at step 116. After 
expansion of the HTTP request, the fixed proxy software 
32 inspects its local cache 44 at step 1 18 to determine 
whether it may have any version of the requested pri- 
mary resource stored locally. Again, the manner in 
55 which the fixed proxy software 32 inspects its local 
cache 44 is described below in conjunction with FIG. 7. 
If the fixed server 30 determines at step 120 that the pri- 
mary resource is not cached locally or if there is a ver- 
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sion of the primary resource cached but that version of 
the primary resource has expired, the fixed proxy soft- 
ware 32 connects to the origin host 50 (e.g., Web site) 
identified in the primary URL (e.g. Web, Gopher, File 
Transfer Protocol, etc.) or to another proxy to retrieve 
the primary resource requested by the mobile client 10 
at step 122. After the fixed proxy software 32 receives a 
valid version of the primary resource either from step 
11 8 or from step 1 25, the fixed proxy software 32 deter- 
mines whether the HTTP response having the primary 
resource is in the form of a HyperText Markup lan- 
guage (HTML) at step 126. 

If the HTTP response is not in a HTML form, the 
fixed proxy software 32 immediately sends the HTTP 
response to the mobile client 10 at step 128 in a token- 
ized and compressed form. The manner in which the 
HTTP response is tokenized is also described below. 
However, if the HTTP response is in a HTML form, the 
fixed proxy software 32 examines the resource identi- 
fied by the primary URL to determine whether the 
mobile client 10 may need any other resources 
("dependent resources", identified by absolute or rela- 
tive URLs in tags in the HTML page) in order for the 
browser 12 to completely display the primary resource 
to the mobile user at step 130 (refer to FIG. 5). For 
example, an HTML page may contain images, Java 
applets, sounds, or other dependent resources which 
must be available for the browser 12 to properly display 
the page. If there are dependent resources identified, 
the fixed proxy software 32 examines its local cache 44, 
and if necessary, reconnects to the origin host 50 iden- 
tified in the primary URL (e.g.. for resources identified 
by relative URLs) or to other hosts (e.g., for resources 
identified by absolute URLs) and issues requests for 
those dependent resources (i.e.. the fixed proxy soft- 
ware pre-fetches the dependent resources identified 
from the primary resource) and receives an updated 
resource from the origin host 50 or from whichever host 
the fixed proxy software 32 requested the resource. If 
the cached version of the primary resource of the 
mobile client 10 is up-to-date, the fixed proxy software 
32 returns an indication that the mobile client 10 has the 
current version of the resource. Otherwise, the fixed 
proxy software 32 transmits the primary resource (in the 
form of a compressed HTTP response), along with 
information identifying the dependent resources upon 
which the primary resource depends, to the mobile cli- 
ent 10 at step 134. 

When the mobile client 10 receives the HTTP 
response at step 136 of FIG. 3, the mobile proxy soft- 
ware 14 expands the HTTP response and updates its 
local cache 26 with the primary resource at step 138. If 
the mobile proxy software 14 determines at step 140 
that the HTTP response the mobile proxy software 14 
received at step 136 is not in a HTML form, the mobile 
proxy software 14 immediately sends the HTTP 
response to the browser 1 2 at step 1 08. However, if the 
mobile proxy software 14 determines at step 140 that 
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the HTTP response it received at step 136 is in a HTML 
form, the mobile proxy software 14 identifies the 
dependent resources at step 142. Using the information 
received from the fixed proxy software 32 regarding the 
dependent resources, the mobile proxy software 14 
examines its local cache 26 to determine whether it has 
any or all of them. Based upon this cache check (as 
described below in conjunction with the discussion of 
FIG 7). the mobile proxy software 14 constructs a short 
acknowledgment list at step 144 which identifies at least 
the dependent resources that are not cached locally at 
the mobile client 10 and the dependent resources that 
are cached locally at the mobile client 10 but have 
expired. The mobile proxy software 14 sends the HTTP 
response having the primary resource to the browser 12 
at step 146 and transmits the acknowledgment list over 
the narrow-band connection to the fixed server 30 at 
step 148. Following step 148, the operation of the 
mobile client 10 again pauses while further steps are 
performed at the fixed server 30 as shown in FIG. 6. 

Returning to FIG. 6, after the fixed server 30 
receives the acknowledgment list from the mobile proxy 
software 14 (at step 150). the fixed proxy software 32 
determines whether there are any dependent resources 
to be sent based upon the acknowledgment list and 
builds a summary response at step 152. The summary 
response comprises one or more status codes (51, 52 
and 53 of FIG. 2), there being one status code for each 
dependent resource (54, 55 and 56 of FIG. 2) requested 
from the mobile client 10 in the acknowledgment list. If 
all of the dependent resources are retrieved by the f ixed 
server 30, there will be one dependent resource for 
each status code in the summary response. If there are 
dependent resources that are not retrieved successfully 
by the fixed server 30, the status code corresponds to 
an error condition (discussed in more detail below) 
which informs the mobile client 10 not to expect those 
particular resources. The summary response may be a 
single transmission (as shown at step 154) or the sum- 
mary response may be fragmented into several trans- 
missions with the status codes for all dependent 
resources included in the first fragment. If the summary 
response is fragmented, the mobile client does not have 
to transmit a reverse channel acknowledgment across 
the narrow-band communications link for the individual 
fragments. Thus, the status codes located in the sum- 
mary response corresponds to those resources, if any, 
that are to follow. 

The mobile client 10 receives from the fixed server 
30 the summary response and the dependent 
resources (if any) at step 156 of FIG. 4. Using the same 
information received from the fixed server 30 regarding 
the dependent resources in the summary response, the 
mobile proxy software 14 modifies its local cache 26 to 
prepare to respond to any forthcoming requests from 
the browser 12 at step 158. Once the cache 26 is pre- 
pared, the mobile proxy software 1 4 responds to the ini- 
tial request from the browser 12, using the primary 
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resource (either from its cache or from the fixed server's 
30 compressed HTTP response) with an HTTP 
response containing the resource identified by the URL 
which the mobile user requested. When the browser 12 
issues a request for any dependent resource, the 5 
mobile proxy software 14 is able to respond immediately 
to the request, or the mobile proxy software 14 is able to 
hold the request until the resource is received from the 
fixed server 30. As the dependent resources are 
received by the mobile proxy software 14, the mobile 10 
proxy software 1 4 updates its local cache and fulfills any 
requests from the browser 12 which have been held. 

FIG. 7 is a flow chart of a method of operation for a 
cache check according to the invention. After a proxy 
examines its cache for a resource at step 1 80, the proxy is 
must determine whether the requested resource is 
present in the cache at step 182 (i.e., whether the proxy 
has previously received the requested resource). If the 
resource is not present, the resource is not cached 
locally. If the resource is present, the proxy must check 20 
the expiration of the resource at step 184. Checking the 
expiration of the resource assures the proxy that the 
resource that is cached is up-to-date within a certain 
time frame (e.g., within 24 hours, etc. (depending on the 
nature of the resource)). If the resource has expired, the 25 
proxy must seek the resource from another source. If 
the resource has not expired, the proxy retrieves a 
dependency list at step 188. The proxy determines 
whether there are any dependent resources at step 
1 90. If there are dependent resources, the proxy checks 30 
the cache further for the dependent resources at step 
192. If the dependent resources are found in the cache, 
the proxy checks the expiration of the dependent 
resources at step 194. If the dependent resources have 
not expired, then they are valid. If the dependent 35 
resources have expired, then the proxy must seek the 
dependent resources from another source. 

Standard HTTP requests and responses consists 
of a request or status line, zero or more headers con- 
sisting of a "field-name", a value and (optionally) an 40 
entity body. The request or status line, and the headers 
are ASCII text, separated by carriage-returns and line- 
feed control characters. The header (the request/ status 
line and the headers, collectively) is always transmitted 
ad the entity body, if present, is transmitted across the 45 
narrow-band communications links uncompressed. The 
wireless Web proxy protocol replaces the standard 
HTTP requests and responses with a binary format con- 
sisting of tokens for the standard parts of the request/ 
status lines and for the standard header "field-names" so 
and common values. Non-standard field-names (e.g., 
"X-" headers) or values are left untouched. 

Tokens are fixed predetermined elements of the 
wireless Web proxy protocol. Each proxy is knowledge- 
able of the information that is tokenized and its corre- 55 
sponding token. The use of tokens allows the "sender" 
proxy to transmit less data across the narrow-band 
communications link. 



Further, request headers and response headers 
are cached at the proxies. Examples of header fields 
are content type, content length, content coding, char- 
acter sets, etc. Having the request and response head- 
ers cached at the proxies allows the "sender" proxy to 
only send new or changed fields in the header across 
the narrow-band connection link to the "recipient" proxy. 

Moreover, certain responses containing "dynamic" 
HTML form consist of a large amount of boiler-plate lan- 
guage and only a small amount of resource-specific 
information (e.g., the result of a search against a search 
engine or database such as an on-line phone directory 
or a stock quote service). Boiler-plate language is spe- 
cific to a HTML page (e.g., the body of a response). 
Thus, with a large boiler-plate language, the possibility 
exists that the user will experience long delays to 
receive only a small portion of resource-specific infor- 
mation. In order to prevent the user from experiencing 
such long delays, the wireless Web proxy system 
caches the response at the respective proxies. When 
the "recipient" proxy request the cached response 
again, the "sender" proxy compares the cached 
response with a current response (e.g., a response 
retrieved from the origin host). The "sender" proxy iden- 
tifies the boiler-plate language between the cached 
response and the current response and only transmit 
the information that is not cached at the "recipient" 
proxy over the narrow-band connection. The "recipient" 
proxy combines the cached information with the infor- 
mation that is received over the narrow-band connec- 
tion to re-construct the complete dynamic response. 

This method is also very useful for responses corre- 
sponding to error conditions. Normally, a response cor- 
responding to a error condition consists of a status-line 
which includes a status code, a reason phrase, a proto- 
col version, zero or more headers and an entity body. 
These elements are essentially static and provide no 
information beyond the status code itself, although they 
usually total to several tens or hundred of bytes. As a 
result, the possibility exists that the user will experience 
long delays because all of the elements are transmitted 
across the narrow-band communications link. The wire- 
less Web proxy system prevents the user from experi- 
encing long delays by caching the above mentioned 
elements at the proxies and transmitting only the status 
code, corresponding to the error condition, across the 
narrow-band communications link. The complete HTTP 
response is constructed, based on the status code, at 
the mobile client and sent to the browser. 

Moreover, as shown in FIG. 2, T1 is the time 
between the initial HTTP request and the time when the 
first response (e.g., the primary response) is transmit- 
ted from the fixed server 30 to the mobile client 1 0. Hav- 
ing a short duration of T1 allows the browser 12 to 
display the general information to the mobile user in a 
short period of time. Allowing the mobile user to quickly 
gain access of general information gives the mobile 
user a opportunity to cancel the request or submit a dif- 
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ferent request before completion of the page if the 
mobile user does not desire to see the entire page (e.g., 
if the mobile user does not like the type of information 
displayed, if the mobile user can obtain what he/she is 
looking for by looking at the general information, etc.). > 

FIG. 8 is a bounce diagram of a alternative embod- 
iment of the invention. The alternative embodiment is 
similar to the preferred embodiment. However, the alter- 
native embodiment does not include the mobile proxy 
software 14 generating and transmitting an acknowl- 
edgment list to the fixed server 30 as does the preferred 
embodiment. Instead, the alternative embodiment 
allows the fixed proxy server 32 to transmit to the mobile 
client 10 a HTTP response having a page and depend- 
ency (HTML) list after the fixed proxy software 32 
retrieves the primary resource and any dependent 
resources. In response to the mobile proxy software 14 
sending the HTTP response to the browser 12, the 
browser 12 submits a HTTP request for the dependent 
resources to the mobile proxy software 14. The fixed 
server 30 transmits the dependent resources to the 
mobile client 10. The mobile proxy software 14 caches 
the dependent resources in its local cache 26 and 
sends the dependent resources to the browser 12 upon 
request. 

With a single request, a primary resource, an 
acknowledgment list and a stream of dependent 
resources in a single transmission, the information nec- 
essary to fully render a complete page of information, 
for example a Web page, can be delivered to the mobile 
user's Web browser 12. While the invention has been 
described in conjunction with a specific embodiment 
thereof, it is evident that many alterations, modifications 
and variations will he apparent to those skilled in the art 
in light of the foregoing description. Thus, it should he 
understood that the invention is not limited by the fore- 
going description, but embraces all such alterations, 
modifications and variations in accordance with the 
spirit and scope of the appended claims. 

Claims 

1. A method of efficient delivery of information, per- 
formed at a fixed server, comprising: 

receiving a HyperText Transport Protocol 
(HTTP) request for a primary resource as iden- 
tified by a uniform resource locator (URL); 
connecting to a host identified in the URL; 
receiving the primary resource from the host; 
inspecting the primary resource to identity 
dependent resources; 

pre-fetching and assembling the dependent 
resources; and 

forwarding the primary resource to a requester. 
2. The method of claim 1 further comprising: 
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caching the dependent resources in a local 
cache; 

waiting for an acknowledgment list from a 
mobile client requesting the dependent 
resources; and 

upon receipt of the acknowledgment list, trans- 
mitting the dependent resources that were 
requested by the mobile client to the mobile cli- 
ent. 

A wireless network proxy having a fixed part and a 
mobile part, the fixed part comprising: 

a first digital processor comprising a resource 
transceiver and a summary response builder 
coupled to the resource transceiver, the sum- 
mary response builder having an output; 
a first radio transceiver coupled to the output of 
the summary response builder for sending at 
least a summary response over a communica- 
tions link to a browser; 

the mobile part comprising: 

the browser; 

a second radio transceiver; 
a cache; and 

a second digital processor having a resource 
transceiver and an acknowledgment list gener- 
ator coupled to the cache and the resource 
transceiver and coupled to the second radio 
transceiver, the acknowledgment list generator 
having a comparator comparing received 
resources with cached resources. 

\. A method of providing resources to a browser com- 
prising: 

sending a HyperText Transport Protocol 
(HTTP) request from the browser to a mobile 
client; 

sending the HTTP request from the mobile cli- 
ent to a fixed server; 

sending the HTTP request from the fixed 
server to an origin host; 
receiving a HTTP response at the fixed server 
from the origin host; 

sending from the fixed server to the mobile cli- 
ent a list of resources; 

at the mobile client, comparing the list of 
resources with resources stored in a cache; 
sending from the mobile client to the fixed 
server an acknowledgment list selectively indi- 
cating resources from the list of resources; 
assembling, at the fixed server, resources 
selectively indicated by the acknowledgment 
list; and 

sending the resources selectively indicated by 
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the acknowledgment list from the fixed server 
to the mobile client in a single transmission. 

5. The method of claim 4 further comprising the step 
of sending each resource from the mobile client to 
the browser upon request. 

6. A method comprising; 
at a fixed server: 

receiving a Hypertext Transfer Protocol 
(HTTP) response from an origin host; 
identifying that the HTTP response corre- 
sponds to an error condition; 
sending a status code to a mobile client; and 

at the mobile client 

constructing a complete HTTP response, 
based on the status code, for delivery to a 
browser. 

7. A method of efficient delivery of information, such 
method comprising: 

transmitting from a mobile client a request 
header in its entirety one time to a fixed server; 
caching the request header at a cache on the 
fixed server; 

for subsequent transmissions of information 
having the request header, transmitting infor- 
mation, different than that contained in the 
request header that is cached at the fixed 
server, from the mobile client to the fixed 
server; 

transmitting from the fixed server a response 
header in its entirety one time to the mobile cli- 
ent; 

caching the response header at a cache on the 
mobile client; and 

for subsequent transmissions of information 
having the response header, transmitting infor- 
mation, different than that contained in the 
response header that is cached at the mobile 
client, from the fixed server to the mobile client. 



has previously cached the resource; 
at the fixed server: 

s examining the resource as currently cached on 

the fixed server; 

requesting the resource from an origin host; 
receiving a HTTP response having an updated 
resource from the origin host; 
10 comparing the resource that is cached with the 

updated resource; and 

sending information to the mobile client which 
when taken together with the resource that is 
currently cached at the mobile client consti- 
is tutes the updated resource. 

9. A method to initiate a transfer of data over a narrow- 
band connection, such method comprising: 
at a fixed server: 

20 

receiving a HyperText Transport Protocol 
(HTTP) request for a primary resource; 
retrieving the primary resource from an origin 
host if the primary resource is not cached at the 

25 fixed server; 

retrieving the primary resource from the origin 
host if the primary resource is cached at the 
fixed server but has expired; 
caching the primary resource at a cache on the 

30 fixed server; 

identifying dependent resources from the pri- 
mary resource; 

requesting from the origin host the dependent 
resources that are not cached locally at the 

35 fixed server; 

requesting from the origin host the dependent 
resources that are cached at the fixed server if 
the dependent resources cached at the fixed 
server have expired; 

40 caching the dependent resources; and 

sending the primary resource to a mobile cli- 
ent. 

10. The method of claim 9 further comprising: 
45 at the mobile client: 



A method of reducing data transfer over a narrow- 
band connection comprising: 
at a mobile client: 

receiving a HyperText Transport Protocol 
(HTTP) request for a resource from a browser; 
examining a cache on the mobile client for the 
resource; 

identifying that the mobile client has already 
received the resource and needs to request the 
resource again; 

informing a fixed server that the mobile client 



50 



55 



caching the primary resource at a cached on 
the mobile client; 

identifying dependent resources from the pri- 
mary resource; 

generating an acknowledgment list identifying 

at least the dependent resources that are not 

cached locally at the mobile client and the 

dependent resources that are cached at the 

mobile client but have expired; 

sending the acknowledgment list to the fixed 

server; 

receiving the dependent resources that are not 
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cached locally at the mobile client and the 
dependent resource that are cached at the 
mobile client but have expired; 
caching the dependent resources at the cache 
on the mobile client; 5 
sending the primary resource to a browser; and 
sending the dependent resources to the 
browser upon request. 



A method at a mobile client comprising: 



receiving a request for a primary resource from 
a browser ; 

checking a cache on the mobile client for the 
primary resource; 15 

if the primary resource is present at the mobile cli- 
ent: 

(i) sending the primary resource to the 20 
browser; 

if the primary resource is present ad has expired at 
the mobile client: 



(i) tokenizing and compressing the request for 
the primary resource; 

(ii) transmitting the request for the primary 
resource to a fixed server; 

(iii) receiving different, updated information for 30 
the primary resource from the fixed server; 

(iv) decompressing the different, updated infor- 
mation for the primary resource; 

(v) assembling the different, updated informa- 
tion received from the fixed server with informa- 35 
tion previously cached at the mobile client for 
the primary resource; 

(vi) updating the cache at the mobile client with 
a complete updated primary resource; and 

(vii) sending the complete updated primary 40 
resource to the browser; 

if the primary resource is not present at the mobile 
client: 

45 

(i) tokenizing and compressing the request for 
the primary resource; 

(ii) transmitting the request for the primary 
resource to a fixed server; 

(iii) receiving the complete updated primary so 
resource from the fixed server; 

(iv) updating the cache at the mobile client with 
the complete updated primary resource; and 

(v) sending the complete updated primary 
resource to the browser. 55 

12. The method of claim 11 further comprising, follow- 
" ing a step of sending the complete updated primary 



resource to the browser, the steps of: 
at the mobile client: 

identifying dependent resources; 
generating a acknowledgment list; 
transmitting the acknowledgment list to the 
fixed server; 

receiving a summary response followed by 
dependent resources from the fixed server; 
10 updating the cache at the mobile client with the 

dependent resources; and 
calculating a plurality of dependent resources. 

1 3. A method at a f ixed server comprising the steps of : 

receiving from a mobile client a request for a 
primary resource; 

checking a cache on the fixed server for the pri- 
mary resource; 

if the primary resource is present and valid at the 
fixed server: 

(i) tokenizing and compressing the primary 
25 resource; and 

(ii) transmitting the primary resource to the 
mobile client; 



if the primary resource is present and stale at the 
fixed server: 

(i) retrieving the primary resource from an ori- 
gin host; 

(ii) caching the primary resource at the fixed 
server; 

(iii) tokenizing and compressing the primary 
resource; and 

(iv) transmitting the primary resource to the 
mobile client, 

if the primary resource is not present at the fixed 
server: 

(i) retrieving the primary resource from a origin 
host; 

(ii) caching the primary resource at the fixed 
server; 

(iii) tokenizing and compressing the primary 
resource; and 

(iv) transmitting the primary resource to the 
mobile client. 

14. The method of claim 13 further comprising: 

pre-fetching dependent resources for the pri- 
mary resource; and 

caching the dependent resources for the pri- 
mary resource at the fixed server. 
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(57) System and method for delivery of information 
over narrow-band communications links. The system 
has at least a browser (12), a mobile client (10), a fixed 
server (30) and an origin host (50). The browser (12) 
requests a resource. The mobile client (10) transmits 
the request to the fixed server (30). The fixed server 
(30) retrieves a primary resource from the origin host 
(50) and any dependent resources. The fixed server 
(30) transmits the primary resource to the mobile client 
(10). The mobile client (10) transmits an acknowledg- 
ment list to the fixed server (30) requesting certain 



dependent resources and sends the primary resource 
to the browser (12). The fixed server (30) transmits the 
requested dependent resources to the mobile client (10) 
in one transmission. The mobile client (10) sends the 
dependent resources to the browser (12) upon request. 
Thus, only transmitting two round-trips of data across 
the narrow-band communications link to transfer all the 
necessary data to create an entire information page 
reduces the delay significantly. 
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